Vendors of phones, tablets, and other mobile computing and communications devices have been increasingly utilizing strong cryptography and cryptographic key management to secure access to the information stored within those devices. At the same time, governments have become concerned about their lack of technical means, in the course of pursuing legally-authorized investigations, to obtain access to the contents of seized devices. Some have argued for the need to create golden keys that could be used by the government to unlock access to such devices on an exceptional basis in legally authorized circumstances. Encryption keys or methods that would provide immediate access or perhaps would yield a differential work factor in trying to access device contents. Others have argued that even with good intent, the creation of such things introduces far too much risk for unintended use or abuse, thus weakening security for those of the majority who are not targets of legally authorized government access.
In general, mobile devices including cell phones, tablets, and other modern computing devices have a secure area within which security critical code and cryptographic data are stored and maintained. Although sometimes implemented in software alone, such a security is now commonly implemented by using a hardware security module, which is referred to as a secure enclave herein.
It is common practice for device providers to leverage the capabilities of the secure enclave to lock and prevent access to a given device by using data protection keys, which are cryptographic keys used directly or indirectly by the system software and firmware of the device to ensure the confidentiality of data contained within the non-volatile storage of the device.
One way of generating or protecting such a data protection key is to use a secret passcode key to prevent unauthorized access. Such a passcode key might be generated by starting with a user supplied password or PIN, which is then tangled with a secret device-unique encryption key by running both through a password-based key derivation function such as PBKDF2-AES. This passcode key may be used directly as a data protection key, or may provide indirect protection of the data protection key through key wrapping using one encryption key to conceal another.
It also is common practice for device providers to leverage the capability of the secure enclave to lock and protect access to a given device by recognizing one or more human fingerprints, scanned by touch sensors, allowing an authorized user to unlock the device as an alternative to entering their password or PIN. These fingerprint sensors, working securely and cooperatively with the secure enclave, then generally use mechanisms such as key wrapping to deliver the ability, for example, one per scanned fingerprint, by which the system software can gain access to the data protection keys. Thus, it is common practice, in existing devices supporting user-supplied passwords or PINS as well as fingerprints, to use key wrapping to provide a number of ways to unlock data protection keys and to provide the ability to unlock a device.
In addition, device vendors verify the authenticity and protect the integrity of system software and firmware of their devices to prevent unauthorized access and modification by malware. This lock-down is generally accomplished by a technique called code signing, wherein cryptographic mechanisms including public key cryptography are used to attach digital signatures to vendor authorized packages of code and other digital resources. A chain of trust is established by using digital signature verification using a vendor's root certificate authority (CA) public key and/or other vendor public keys generally contained in the read-only memory of the device, or which may be securely stored within a secure enclave.
A vendor creating, maintaining, and using vendor keys must do so with great care, for carelessness that might for example cause disclosure of a private key, misuse of the private key, or substitution of an unauthentic public key would cause a fundamental breakdown of trust. So critical is this trust that vendor private keys are generally stored and maintained exclusively within one or more enterprise-grade hardware security modules (HSMs) at their facilities. Vendors generally maintain strict internal processes and practices so that only their trusted developers and trusted software release engineers are authorized to attach digital signatures to software, firmware, and other digital resources, thus ensuring the integrity and provenance of all digital assets signed, encrypted, and decrypted with the vendor keys.
Previous methods for providing government agencies with access involve a key escrow method where decryption keys are used. Key escrow, however, is widely viewed as a high-risk solution for vendors and their customers because the standards vary, it subjects key holders to potential coercion, and motivations of key holders can change over time. Vendors must bear the business risk, market risk, and reputation risk of properly handling their vendor keys. The vendors must do this for cybersecurity reasons, so that they can securely deliver updates to their customers' devices.
What is needed is a method or system that allows a vendor to use its vendor keys to provide low risk access to government agencies and the like to locked devices, real-time communications, and secure messaging.